Match type filters through re-export spellings via canonical code refs - #5800

[Claude Code 🤖] Out-of-order canonicalization leaves a stale source and stickily disables client reconciliation (regression introduced by this PR; non-blocking — it degrades to a safe server-only passthrough, but silently and until the next query change).

The mechanism. loadCanonicalizedFilter runs on every live modify() (search.ts :424, before this.activeQuery = query at :426). Its early-return guard (this.canonicalizedFilter?.source === filter, :269) compares only against the settled value, so while a first canonicalization for filter A is still in flight, a second modify() carrying filter B (a new object) passes the guard and starts a second concurrent canonicalizeFilterRefs. This .then then writes canonicalizedFilter = { source: filter, … } unconditionally, so whichever promise settles last wins.

The two resolutions are loader.import(ref.module) calls: A triggers the cold import (possibly a network fetch); B, arriving later, resolves the same module from the loader cache almost immediately. So B settles first and sets source: B, then A settles and clobbers it with source: A. Now this.activeQuery.filter === B but this.canonicalizedFilter.source === A.

The consequence. isClientFilterEligible requires canonicalized.source === filter (:712–717), so a stale source makes it return false and displayedInstances returns the server set untouched (:589–593). Results stay correct, but live client-side reconciliation (candidate add + local no-match removal) stays off until the next modify() whose canonicalization happens to win the race — a live-refresh realm event calls this.search.perform(this.#previousQuery) without re-running modify(), so nothing re-triggers it in between. Sticky.

The fix. Drop a stale result in the .then. It fires synchronously after this.activeQuery = query is set within the same modify(), so activeQuery.filter is already the latest by the time any resolution lands:

Related. Because the guard and memo key on filter object identity, an unstable () => query thunk that rebuilds a deeply-equal filter on each recompute re-triggers canonicalization (and a transient passthrough window) on every modify(), even though the querySignature deep-equal check at :537 already skips the redundant search. Keying eligibility off querySignature rather than identity would also close that gap — but the staleness guard above is the load-bearing fix.

Non-blocking.

[Claude Code 🤖] Fixed in 2a58eb1006. The .then now drops its result when this.activeQuery?.filter !== filter, so a late resolution (a cold loader.import settling after a cache-warm sibling) can no longer overwrite canonicalizedFilter with a source that points at a filter that is no longer active. The guard is sound because the .then fires only after this.activeQuery = query has run synchronously within the same modify(), so the comparison always sees the current filter.

The related identity-keying note (an unstable () => query thunk re-triggering canonicalization) is left as-is — the staleness guard makes the transient passthrough self-correct, and moving eligibility onto querySignature is a larger change than this finding warrants.

[Claude Code 🤖] typeKeysFor swallows every lookupDefinition error, so a transient definition-lookup failure silently under-matches (follow-up / non-blocking; the not-found case matches prior behavior).

This catch {} treats all failures the same — fall back to spelling-only keys. For a genuinely nonexistent type that's correct and matches the pre-existing behavior (a bare { type: X } filter never validated existence). But lookupDefinition can also throw transiently — a prerender timeout or module-cache miss under load, a DB hiccup — and on a valid re-export ref (file-api's FileDef) that means the canonical (card-api) key never joins keys, so the query silently returns fewer rows (the canonical-stamped rows drop out) with no error surfaced. The engine raises FilterRefersToNonexistentTypeError for field-path lookups elsewhere; a type condition now carries the same async dependency but degrades silently instead.

Not this PR's blocker: the failure is transient and self-heals on retry, and the canonical-key expansion is what's new here rather than the whole type filter. Worth considering whether to distinguish "definition not found" (fall through, match nothing — fine) from an unexpected lookup error (surface it, as the field-path walk does). Non-blocking.

[Claude Code 🤖] Fixed in 2a58eb1006. The blanket catch {} is now catch (error) that re-throws unless isFilterRefersToNonexistentTypeError(error). A ref resolving to no known type still falls through to the spelling-based keys — matching how the engine already treats a nonexistent type as an empty result (the top-level _search catch), so the intentional spelling-key fallback and the transient-module-error behavior are unchanged. What changes is that a genuinely unexpected error (a bug, not a missing type) now propagates instead of being silently swallowed and narrowing the match.

Note the engine deliberately treats a FilterRefersToNonexistentType — which wraps transient module/prerender errors too — as match-nothing everywhere (field-path lookups included), so this keeps typeKeysFor consistent with that convention rather than special-casing transient failures here.